kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19980424-19980901/000121_news@newsmaster….columbia.edu _Sat May 23 05:02:19 1998.msg

Internet Message Format | 1998-08-31 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id FAA27908
    for <[e-mail]>; Sat, 23 May 1998 05:02:18 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id FAA19431
    for kermit.misc@watsun; Sat, 23 May 1998 05:02:18 -0400 (EDT)
Path: news.columbia.edu!panix!howland.erols.net!Supernews73!supernews.com!nntp.flash.net!scanner.worldgate.com!rover.ucs.ualberta.ca!news.ucalgary.ca!acs2.acs.ucalgary.ca!mmastrac
From: Matthew Mastracci <[e-mail]>
Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
Date: Sat, 23 May 1998 02:13:14 -0600
Organization: The University of Calgary
Lines: 102
Message-ID: <6k60eq$[e-mail]>
References: <[e-mail]> <6k1qoj$d92$[e-mail]> <[e-mail]> <6k42pd$a3m$[e-mail]>
NNTP-Posting-Host: [e-mail]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To: Frank da Cruz <[e-mail]>
In-Reply-To: <6k42pd$a3m$[e-mail]>
Xref: news.columbia.edu comp.protocols.kermit.misc:8776 comp.sys.hp48:81349

On 22 May 1998, Frank da Cruz wrote:

> As noted in an earlier posting in this thread, I would like to straighten
> out the massive confusion about Kermit file transfer with the HP-48.  We (at
> the Kermit Project) are not HP-48 experts, but we do have an early model
> HP-48 for testing.  When we get complaints or questions about file transfer
> with the HP-48, we check our answers on it.

I've written a Kermit program for transferring between the PC and the
HP48, so I'd like to offer my discoveries (I've spent a long time getting
my client to connect to the calculator).

>  1. The top serial speed is 9600, right?

Yes.

>  2. Should the flow control setting be NONE or XON/XOFF?  We have
>     conflicting reports (see above).  Obviously the HP-48 *should* be
>     exercising some form of flow control, but some reports indicate that
>     it does not (even if it is set to do so).

The calculation doesn't need flow control, as the size of a packet will
never exceed the internal buffer (sliding windows aren't supported).
Having XON/XOFF interferes with the transfer, from what I can tell, as the
HP48 picks the control characters up as unquoted data.  I can tell you
*absolutely* that flow control is not required.

>  3. Is the link transparent to incoming control characters?  Can the
>     client Kermit program use control-character unprefixing when sending
>     to the HP-48?  If not, the client program must be told to
>     SET CONTROL PREFIX ALL prior to sending files to the HP-48.

The link is transparent to all characters.  The HP48 will reject any
packet that contains an unquoted control character with a NAK packet (this
is probably because the calculator can also send via IR, which may
introduce errors).  Control-character prefixing must be used to send to
the HP48.

>  4. Does the link allow 8-bit data?  If not, the client must be given
>     the appropriate SET PARITY command.

The default setting for the HP48's serial port is 9600 baud, no parity, 8
bits and 1 stop bit.  If it has been set to something else, you can
restore it to this default by deleting the IOPAR variable.

> The HP-48 does not support long packets; thus the maximum packet length
> is 94, but this should be negotiated automatically.

This is negotiated properly.

> The HP communication port is half duplex, meaning that data can go in both
> directions, but only in one direction at a time.  Therefore sliding windows
> can not be used (this too should be negotiated automatically).

Yes.  The HP48's info is something like "~* @-#N1".

> More to the point, I have also heard that (at least some models of) the
> HP-48 become "deaf" to incoming bytes for some number of milliseconds while
> switching their serial port from "send" to "receive", so if the client
> program is too fast, file transfers can fail.  The solution to this is to
> tell the client program to pause for a sufficient number of milliseconds
> prior to sending each packet:

This only happens every dozen packets or so.  A client that can resubmit a
NAK'd packet will be able to recover from this.  If you watch a transfer
at high speeds, you'll see every few packets fail (for no apparent reason:
the link cable is a very clean line).  Setting the flag you mentioned will
fix the problem.

> Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
> "parses" incoming text-mode material on the fly, and appends the material
> from each incoming packet to a "string", resulting in a steadily
> deteriorating transfer rate, at least up to some point at which the HP-48
> dumps the string to storage and starts over with a new string.  There's not
> much that the Kermit client can do about that.

Actually, it has to copy the *entire* received buffer for each packet,
from what I understand.

> Any other hints from HP-48 users will be appreciated; I'll be glad to
> collect them into an FAQ.

The '48 is very picky about some aspects of the Kermit protocol.  Here are
a few additional points about the HP48's server:

 - The only way to change the working directory is with a command packet
that reads: { Relative_directory_name } EVAL
 - Each command packet will send back data containing a stack dump.
 - Directory dumps are in the format:
---
{ Current_directory } Free_space
Object_name Object_size_bytes Object_type Object_CRC
... etc ...
---
 - Error packets should contain CR+LF (#M#J) at the end of the string
 - You can shut the HP48's server down with a 'G' packet, data "F"

/\/\att /\/\astracci                  [e-mail]

"Tout choses sont dites deja, mais comme personne n'ecoute, il faut
toujours recommencer."